Security risks, such as allowing unauthorized access to a user's system, are inherent with many on-line activities. Therefore, security mechanisms have been developed to protect users' systems. For example, a user may download an on-demand application from the Internet and execute the application from within the browser. To prevent an unauthorized access to the user's system resources (e.g., a directory on the user's hard disk), the user's system is protected by “sandbox” security that is enforced within the browser environment. Sandbox security involves a limited, secure area of computer memory in which an application may execute, so that the application is prevented from accessing system resources that reside outside of the secure area.
In some circumstances, however, a user may wish to allow a downloaded application controlled access to certain resources within the user's system. For example, a user may wish to use an on-demand word processing application to generate a document and then save the document to a directory in the user's system.
Existing approaches for providing such applications with secure, controlled access to a user's system are too cumbersome and inflexible. In one method, for example, a security policy is defined within a policy database in which a given application is associated with a set of permissions. The security policy, in combination with origin information, signature information, and access restrictions, helps define a “trusted” relationship between the application and the user's system.
Consider the following example:
grant codeBase “http://www.BobsWidgets.com” signed byBobsCertificate {    permission lang.io.FilePermission “/tmp/” “read”;    permission lang.io.FilePermission “/tmp/bwdir/*” “write”;}
In the example, an applet from the source location, “www.BobsWidgets.com”, is granted certain file access permissions if it is signed with a key corresponding to another key contained within BobsCertificate. An applet is traditionally a program designed to be executed from within a browser, rather than directly from within the operating system. The applet is granted permission to read files from the “/tmp” directory on the host system and to create and write to files in the “/tmp/bwdir” directory. Permission to “execute” is another common permission modifier. Other security policy specifications may, for example, grant broad permissions to access any file in any system location, regardless of the application's source or whether the application is unsigned or signed.
In such approaches, a security policy manager uses self-verifying information, such as the certificate, to determine which permissions the applet (or any code assembly) should be granted. However, in some situations, the information associated with the applet is not self-verifying and may be considered “untrusted”. For example, assume that a user has installed an encryption library on a computer system after purchasing a restricted license allowing the user to call the library from a given application. At some later point, the user may attempt to download and execute a different application that also includes calls to the encryption library. A code assembly within the second application may include an embedded certificate, signed by the library vendor, indicating that the code assembly vendor has also purchased rights to call the vendor's library on a user's system. However, because the certificate is provided by the application vendor and not the library vendor, the certificate may be untrusted.
By relying upon untrusted information, a policy manager may improperly grant permissions to the applet or application and expose the system to security risks. The unanswered problem is how to safely determine the appropriate permissions to be granted to an application (or any code assembly) using potentially untrustworthy information. In addition, there has yet to be a way for policy managers to enforce and grant trust to code assemblies executing in the context of a particular application.